SSH keys stored and managed in a project’s metadata can be used to access GCP VM instances. By default, GCP automatically deploys project-level SSH
keys to VM instances.
Project-level SSH keys can lead to unauthorized access because:
- Their use prevents fine-grained VM-level access control and makes it difficult to follow the principle of least privilege.
- Unlike managed access control with OS Login, manual
cryptographic key management is error-prone and requires careful attention. For example, if a user leaves a project, their SSH keys should be
removed from the metadata to prevent unwanted access.
- If a project-level SSH key is compromised, all VM instances may be compromised.
Ask Yourself Whether
- VM instances in a project have different security requirements.
- Many users with different profiles need access to the VM instances in that project.
There is a risk if you answered yes to any of those questions.
Recommended Secure Coding Practices
- Block project-level SSH keys by setting the
metadata.block-project-ssh-keys argument to true
- Use OSLogin to
benefit from managed access control.
Sensitive Code Example
resource "google_compute_instance" "example" { # Sensitive, because metadata.block-project-ssh-keys is not set to true
name = "example"
machine_type = "e2-micro"
zone = "us-central1-a"
network_interface {
network = "default"
access_config {
}
}
}
Compliant Solution
resource "google_compute_instance" "example" {
name = "example"
machine_type = "e2-micro"
zone = "us-central1-a"
metadata = {
block-project-ssh-keys = true
}
network_interface {
network = "default"
access_config {
}
}
}
See
